The general packet radio service (GPRS) is a packet oriented mobile data service for cellular communications systems, such as the global system for mobile communications (GSM), wideband code division multiple access (WCDMA), long term evolution (LTE) and wireless local area network (WLAN). A general packet radio system (GPRS) tunneling protocol user (GTP-U) node supports one or more GTP-U endpoints. Each pair of GTP-U endpoints is known as a GTP-U path which carries multiple GTP-U tunnels. GTP-U tunnels carry GTP-U data packets (also known as G-PDUs) between a pair of GTP-U tunnel endpoints. A tunnel endpoint is identified by a tunnel identifier, e.g., tunnel endpoint identifier (TEID).
A TEID identifies a unicast or multicast GTP-U tunnel endpoint in the receiving GTP-U node for a given GTP-U endpoint. The TEID is included in the GTP header of the G-PDU. The receiving end of a unicast GPRS tunneling protocol, GTP, tunnel assigns the TEID value that the transmitting end should use. The transmitting end of a multicast GTP tunnel assigns the TEID value the receiving end should use. The TEID values are exchanged between tunnel endpoints using control plane messaging.
The control plane procedures to setup a GTP-U tunnel are defined in protocols such as GTP-C, Radio Access Network Application Part (RANAP), S1-Application Protocol (S1-AP), X2 Application Protocol (X2-AP) and M3 Application Protocol (M3AP).
FIGS. 1 and 2 show a known GPRS 10 which includes three GTP-U nodes 12a, 12b and 12c (referred to collectively herein as “GTP-U nodes 12”) that are connected by an Internet Protocol (IP) network 18. Each GTP-U node acts as a sender and a receiver of G-PDUs. FIG. 1 shows a unicast G-PDU being sent between GTP-U nodes 12c and 12a. FIG. 2 shows the same known GPRS 10 with the three GTP-U nodes 12a, 12b and 12c connected by the Internet network 18. In FIG. 2, a multicast G-PDU is being sent from GTP-U node 12a to GTP-U node 12b and to GTP-U node 12c. 
Active IP probe based sampling of the IP path carrying the GTP-U tunneled traffic is currently used as a methodology for estimating the end-to-end state and performance of the unicast subscriber connection across the IP network. However, active IP probe based sampling does not measure the actual packet delay, packet delay variation and packet loss encountered by the user traffic carried on unicast GTP-U tunnels. The same problem exists for multicast GTP-U tunnels. Active IP probe based sampling, like the One-Way Active Measurement Protocol (OWAMP) and Two-Way Active Measurement Protocol (TWAMP), only provide a rough estimate of the performance perceived by the aggregated set of GTP-U tunnels on a given path.
The Internet engineering task force (IETF) standard body has defined an IP flow information export (IPFIX) architecture and protocol for selective monitoring of IP flows passing through an observation point and the export of measured IP flow information. IPFIX does not address the selective monitoring of GTP-U tunnels. IP flow information export does not provide the required granularity and depth of information to properly monitor the performance of a specific GTP-U tunnel. Furthermore, IPFIX is not designed to provide path performance statistics like end-to-end packet delay and packet loss. Such statistics are useful for characterizing tunnel performance.
Carrier-grade WLAN networks are implemented using Access Points (APs) and Access Controllers (ACs). The APs are distributed small cell nodes responsible for providing 802.11 radio services to users and subscribers in outdoor and/or in-door Wi-Fi coverage areas. The APs communicate with one or more Access Controllers (ACs) over a backhaul network. The backhaul network can be an IPv4 network, an IPv6 network, an Ethernet LAN network, a wireless mesh network or any other mix of wired or wireless Layer 2 (L2) technologies including a very high bit rate digital subscriber line/asymmetric digital subscriber line (VDSL/ADSL) and cable modem. The AC manages the control and data traffic from a group of APs. The AC improves Wi-Fi services delivery in large venues and enterprises, as well as small to medium sized businesses and 3G/4G offload scenarios. The AC provides a single point of management and increased security by creating secure connections to each AP.
A communication protocol used between the AP and AC is the Control And Provisioning of Wireless Access Points (CAPWAP) protocol. The CAPWAP protocol is composed of two distinct user datagram protocol/Internet protocol (UDP/IP) flows: the CAPWAP control channel and the CAPWAP data channel.
The CAPWAP control channel requires that control messages be defined in pairs, consisting of both a Request and a corresponding Response message from the peer. Therefore, the CAPWAP control channel is referred to herein as a bi-directional control channel. Examples of CAPWAP control messages are:                Discovery Request/Response (request originates from AP)        Join Request/Response (request originates from AP)        Configuration Status Request/Response (request originates from AP)        Configuration Update Request/Response (request originates from AC)        Wireless Transaction Protocol (WTP) Event Request/Response (request originates from AP)        Change State Event Request/Response (request originates from AP)        Echo Request/Response (request originates from AP)        Image Data Request/Response (request originates from AP or AC)        Reset Request/Response (request originates from AC)        Primary Discovery Request/Response (request originates from AP)        Data Transfer Request/Response (request originates from AP or AC)        Clear Configuration Request/Response (request originates from AC)        Station Configuration Request/Response (request originates from AC).        
Monitoring the performance of the CAPWAP control channel (separately from the CAPWAP data channel) is critical to the performance of a WLAN network. The CAPWAP control channel does not carry any user data but it is used for many vital Wi-Fi network functions such as discovery, request for service, keep-alive, configuration, radio statistics reporting, firmware/software management, alarm notification, etc.
Active IP probe based sampling of the paths carrying the CAPWAP control traffic can be used as a methodology for estimating the end-to-end state and performance of the CAPWAP control channels across the IP network. However active IP probe based sampling does not measure the actual control packet delay, control packet delay variation, control packet loss and control packet mis-ordering encountered by the CAPWAP control traffic. Active IP probe based sampling like the One-Way Active Measurement Protocol (OWAMP) and Two-Way Active Measurement Protocol (TWAMP) only provide a rough estimate of the performance perceived by the aggregated CAPWAP control traffic on a given direction of a path.
The Internet Engineering Task Force (IETF) standards body has defined an IP flow information export (IPFIX) architecture and protocol for selective monitoring of IP flows passing through an observation point and the export of measured IP flow information. IPFIX does not address the selective monitoring of CAPWAP control channels. IP flow information export does not provide the required granularity and depth of information to properly monitor the performance of a specific CAPWAP control channel. Furthermore, IPFIX is not designed to provide path or end-to-end connection performance statistics like end-to-end packet delay and packet loss.
The IETF standards body has defined an information management base (MIB) for the CAPWAP protocol. Unfortunately, it does not specify any CAPWAP channel endpoint statistics or counters. It also does not include any end-to-end CAPWAP control channel or flow performance statistics since the currently defined CAPWAP protocol version is not able to generate one-way or two-way channel performance metrics.
GTP-U connections and real time transport protocol (RTP) sessions are made of pairs of unidirectional GTP-U tunnels or RTP flows and the GTP-U/RTP. One-way measurement methods for one-way GTP-U tunnels and RTP flows are not applicable or sufficient to handle the monitoring of CAPWAP control channels since the CAPWAP control channel is a two-way signaling protocol.